home *** CD-ROM | disk | FTP | other *** search
-
-
-
- - 1 -
-
-
-
- 7.2.1 (BETA) C++ Release Notes
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- DDDDooooccccuuuummmmeeeennnntttt NNNNuuuummmmbbbbeeeerrrr 000000007777....2222666600006666----000011110000
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 2 -
-
-
-
- 1. _D_y_n_a_m_i_c__S_h_a_r_e_d__O_b_j_e_c_t_s
-
- A Dynamic Shared Object, or DSO, is an ELF format object
- file, very similar in structure to an executable program but
- with no "main". It has a shared component, consisting of
- shared text and read-only data; a private component,
- consisting of data and the GOT (Global Offset Table);
- several sections that hold information necessary to load and
- link the object; and a liblist, the list of other shared
- objects referenced by this object. Most of the libraries
- supplied by SGI are available as dynamic shared objects.
-
- _N_O_T_E: When building a DSO containing C++ objects, the link
- step mmmmuuuusssstttt be performed using the _C_C command, instead
- of using _l_d directly. Follow the instructions in the
- _d_s_o(_5) man page exactly, except that you must
- substitute _C_C wherever that man page says _l_d.
-
- A DSO is relocatable at runtime; it can be loaded at any
- virtual address. A consequence of this is that all
- references to external symbols must be resolved at runtime.
- References from the private region (.e.g. from private data)
- are resolved once at load-time; references from the shared
- region (e.g. from shared text) must go through an
- indirection table (GOT) and hence have a small performance
- penalty associated with them.
-
- Code compiled for use in a shared object is referred to as
- Position Independent Code (PIC), whereas non-PIC is usually
- referred to as non-shared. Non-shared code and PIC cannot
- be mixed in the same object.
-
- At Runtime, eeeexxxxeeeecccc loads the main program and then loads rrrrlllldddd,,,,
- the runtime linking loader, which finishes the exec
- operation. Starting with main's liblist, rrrrlllldddd loads each
- shared object on the list, reads that object's liblist, and
- repeats the operation until all shared objects have been
- loaded. Next, rrrrlllldddd allocates common and fixes up symbolic
- references in each loaded object. (This is necessary
- because we don't know until runtime where the object will be
- loaded.) Next, each object's _i_n_i_t code is executed.
- Finally, control is transferred to "__start".
-
- For a more complete discussion of DSOs, including answers to
- questions frequently asked about them, see the _d_s_o(_5) man
- page.
-
-
-
-
-
-
-
-
-
-
-
-
-
-